Sumo Logic – AWS Observability Solution について

最初に

Sumo Logic における AWS Observability Solution とは、主要な AWS インフラの運用上の洞察を得る時間を短縮できる機能です。 これにより、組織はリソースで発生している問題が与える影響を最小限に抑えることが出来ます。

今回は、AWS Observability Solution を展開するための設定と、完成したダッシュボードを一部ご紹介したいと思います。

AWS Observability の設定

まず最初に Sumo Logic と安全に接続するために Sumo Logic 側で「アクセス ID / キー」を発行する必要があります。

手順
Administration > Security > Access Keys で、+ ボタンを押下。Access Key Name を入力して、Save を押下した時に出る Access ID / Access Key の両方をコピーする。 ※ Access Key は、ここでしかコピーできません。必ずどこかにメモしておいてください。

コピーが出来たら、次に Sumo Logic の Organization ID を取得します。

手順
Administration > Account > Account Overview の Organization ID に表示されている英数字をコピー。

ここまでで、Sumo Logic 側で必要な情報は揃いました。次は、アクセス権限周りのテストを行います。

AWS と Sumo Logic 側の権限テスト

Sumo Logic では、AWS Observability を展開するために権限周りのテスト用の AWS CloudFormation テンプレートを公開しています。参考元：Before You Deploy - Verify AWS and Sumo Logic Permissions | Sumo Logic Docs

sumologic-solution-templates | Sumo Logic Github で、必要なロールが割り当てられているかを確認してください。

なお、建てられるリソースは、AWS Observability Resources | Sumo Logic Docs で確認いただけます。

手順
上記サイトの 権限テスト用の AWS CloudFormation テンプレートをダウンロード

そしたら、AWS CloudForamtion の画面に移動して、スタックの作成を押下します。すると、下記の画面に遷移します。

その後、「テンプレートの準備完了」「テンプレートファイルのアップロード」を選択して、先ほどダウンロードした .yaml ファイルをアップロードします。 完了したら、「次へ」を押下すると、下記の画面に遷移します。

ここでは、冒頭ご説明した Access ID / Access Key と Sumo Logic Org ID を入力していきます。入力が完了したら「次へ」を押下します。これ以降は何も入力せずに進んでいただき、最後に「送信」を押下して、テンプレートが正常に実行されるのを確認します。

本番用テンプレートのデプロイ設定

sumologic_observability.master.template.yaml という本番展開用の Cloud Formation テンプレートを使って、Cloud Formation のスタック作成画面で、テンプレートファイルをアップロードするか、S3 URL（https://sumologic-appdev-aws-sam-apps.s3.amazonaws.com/aws-observability-versions/v2.6.0/sumologic_observability.master.template.yaml） を使用します。

それでは、Deploy with AWS CloudFormation | Sumo Logic を参考に 1個ずつ見ていきます。

1. Sumo Logic Access Configuration (Required)

こちらは、権限テストのテンプレートの設定と同じように入力してください。Delete Sumo Logic Resources when stack is deleted の項目については、true を推奨します。デプロイ失敗の際にリソースを削除するかどうかの設定です。

ここでは、AWS アカウントのエイリアスを入力します。後に Sumo Logic 側でこのエイリアス名が表示されますので、何の目的で使用されているアカウントかが分かる名前が好まれます。

S3 Object URL of a CSV file that maps AWS Account IDs to an Account Alias の項目は、複数 AWS アカウントがある場合に各アカウントにマッピングするための CSV を S3 にアップロードしてあれば、その S3 URL を入力します。特に今回の様に単一アカウントを対象とする場合は、空白で OK です。

Yes を選択した場合、各リソース（AWS EC2、AWS Application Load Balancer、Amazon RDS、AWS API Gateway、AWS Lambda、Amazon DynamoDB、AWS ECS、Amazon ElastiCache、Amazon Classic Load Balancer、AWS NLB、Amazon SNS、Amazon SQS）を可視化するダッシュボードが形成されます。また、可観測性のために Sumo Logic 側でアラートも設定されます。

AWS CloudWatch Metrics のデータを収集する Sumo Logic の Source を作成します。コスト面では、Kinesis Firehose Metrics Source を推奨します。

Sumo Logic AWS Metrics Namespaces の項目では、メトリクスの名前空間を設定します。これにより、除外したいメトリクスの選別が可能になります。

Existing Sumo Logic Metrics Source API URL の項目は、Sumo Logic 側に既存の Metrics Source がある場合にその Sumo Logic API URL を入力します。

New を選択すると、新たに作成された ALB のログを収集します。Existing は、既存のもののみを収集。Both は、New と Existing 両方。None は収集しません。

Create Sumo Logic ALB Logs Source の項目は、Sumo Logic 側に新規の Source を作成するかどうかの確認です。

Existing Sumo Logic ALB Logs Source API URL の項目は、Sumo Logic 側に既存の Log Source がある場合にその Sumo Logic API URL を入力します。

Amazon S3 Bucket Name の項目は、ALB ログを保存する既存の S3 バケット名を指定します。次の項目 Path Expression for existing ALB logs に既存の S3 パスを入力します。

Sumo Logic 側に既存の CloudTrail Log Source が存在するかどうかを確認されています。

Existing Sumo Logic CloudTrail Logs Source API URL の項目では、Yes を選択した場合にその Log Source の API URL を入力します。

Amazon S3 Bucket Name の項目は、CloudTrail ログを保存する既存の S3 バケット名を指定します。次の項目 Path Expression for existing CloudTrail logs に既存の S3 パスを入力します。

Existing Sumo Logic Lambda CloudWatch Logs Source API URL の項目は、既存の Lambda CloudWatch Source が存在する場合にその Source API URL を入力します。

CloudWatch Logs の Source を作成するか確認されています。Lambda Log Forwarder で、Lmabda を使用したログ送信を行います。Kinesis Firehose Log Source は、Kinesis Firehose をパイプラインとした ログ送信を行います。Both は、Lambda Log Forwarder を Kinesis Firehose Log Source に変更します。この時、すべてのロググループは Kinesis Firehose にサブスクライブしてくれます。

Subscribe log groups to Sumo Logic CloudWatch Logs Forwarder の項目は、AWS Observability Solution を展開するために収集されるログのロググループを Lambda にサブスクライブさせるかどうかを確認されています。New は新しいもののみを収集。Existing は、既存のもの。Both は、New と Existing 両方。None はサブスクライブをさせません。

Regex for AWS Lambda Log Groups の項目は、ロググループにマッチする正規表現を入力します。Configuring parameters | Sumo Logic Docs を参考に入力します。

Sumo Logic の Root Cause Explorer という機能を使用する場合の Source について確認されています。アプリや、マイクロサービスにおける問題の根本原因を迅速に特定するソリューションでして、CloudWatch のメトリクスを収集します。その Source のタイプが、Inventory Source（主にインフラのスパイクやスロットルの状況を判断できます。）か X-Ray Source（主にレイテンシー、スループット、エラー率などのアプリケーション間のサービスレベルのメトリクスを収集します。サービスマップも使えます。）、もしくは両方とも入れるかを確認されています。

確認項目 ⑤ の CLB 版になります。

最後に AWS Observability Solution を Sumo Logic の個人フォルダに配置するか、誰もが見れる ADMIN RECOMMENDED に配置するかを確認されています。また、次の項目では、Sumo Logic アカウントすべてに対して閲覧権限を与えるか否かを確認されています。

承諾として、チェックボックスにチェックを入れます。

15 ~ 20 分ほど待機して、下記の様に CREATE_COMPLETE と出ていれば完了です。

あとは、Sumo Logic のフォルダを確認してデータを見ていただけます。一例になりますが、EC2 インスタンスの場合、この様に必要な項目を見るために難しいクエリを書かずに表示してくれるようになります。

まとめ

いかがでしたでしょうか？AWS Observability Solution を展開していただくと、これらの主要なリソース（AWS EC2、AWS Application Load Balancer、Amazon RDS、AWS API Gateway、AWS Lambda、Amazon DynamoDB、AWS ECS、Amazon ElastiCache、Amazon Classic Load Balancer、AWS NLB、Amazon SNS、Amazon SQS）を可視化することが出来ます。AWS 側に権限がなくとも、運用者に Sumo Logic のアカウントで閲覧権限を設定されていれば、この様に可視化された運用状況を確認することが出来るのも１つメリットです。 少し長い設定だったので、まとめてみました。誰かの一助になれば幸いです。